home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / mail / pine / imap_archive / text0075.txt < prev    next >
Encoding:
Text File  |  1993-07-02  |  1.5 KB  |  43 lines
  1. On Sun, 18 Apr 1993, Mark Crispin wrote:
  2.  
  3. > Yes, just plain unparsed strings would be returned.  I don't particularly
  4. > understand why you would want to address-parse the ReSent-* strings (other
  5. > than perhaps to canonicalize their format), but as you point out the routines
  6. > you need are in c-client anyway.
  7.  
  8. OK, The reason I had in mind was canonicalization of their format for
  9. presentation to the user -- it's a nice thing to keep all the addresses
  10. looking similar.
  11.  
  12.  
  13. > > It sounds like you have a choice of requesting the header lines that you
  14. > > want, one at a time, or parsing a big string that comes back. The problem
  15. > > with requesting the lines one at a time would be an RTT for each one,
  16. > > right?
  17. > 
  18. > Yes, that's correct.  The real intent is to be able to gobble down the useful
  19. > header lines in addition to what the envelope gives to you and possibly just
  20. > blat them to the screen without any processing.
  21.  
  22. I'm a little concerned about RTT's in a mailer that regularly fetches the
  23. Resent-XXX:, References:  and other fields (presumably many if not most
  24. good IMAP clients will do this). You're probably one to think about this
  25. more than I, but wouldn't it at least double the number of RTT's for a lot
  26. of the normal operations? Is doubling the RTT's a problem? I know there's
  27. probably not much else that can be done without breaking existing IMAP
  28. clients. 
  29.  
  30. Laurence Lundblade
  31.   lgl@csgrad.cs.vt.edu or lgl@cac.washington.edu (both forward to same place)
  32.      Blacksburg, Virginia or  Seattle, Washington
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.